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BRIEF SUMMARY OF THE INVENTION 



An embodiment of the present invention is an enhancement to a web browser, and 
provides methods for gathering and organizing web pages into a navigable, integral 
apparatus with contextual communications built-in, which apparatus can then be 
displayed in any web browser. As the user navigates the internet with their web browser, 
the present invention enables them, at the click of a button, to quickly add the web page 
currently displayed in the web browser to a "webpipe". A webpipe is collection of web 
pages selected by the author of the webpipe; the webpipe is navigable by clicking 
sequentially through each page or by jumping to a page via a hyperlink. In addition, 
message boards and other communication tools are integrated into the webpipe which 
allow contextual communications with others who receive the webpipe. Methods of the 
present invention also enable a user of said invention to link online content to digital 
media. For example, the present invention enables a user to create a webpipe of 
information about a certain band, and then link said webpipe to a song by that band. 
Whenever anyone plays the same song on their computer, that person can view the 
webpipe created by the author. For instance, if a user is viewing a web page concerned 
with income tax issues, the present invention allows for third parties not connected with 
the web page in question to present their goods or services to the user. In this case, 
attorneys specializing in tax law can present their services to the user. An embodiment of 
the present invention enables automatic, context-sensitive search triggered by and 
relevant to the playing of digital media on a computer. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows Microsoft Internet Explorer with the SidePipe button installed 
Figure 2 an exemplary flow diagram illustrating the authoring of a webpipe 
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BACKGROUND OF THE INVENTION 



The present invention relates generally to the field of internet communication, 
collaboration, and search for relevant document on the internet. More specifically, the 
present invention is directed to gathering web pages from the internet into a cohesive unit 
and associating communications by third parties onto those pages, and in providing a new 
method of obtaining and displaying web page search results. 

The internet and the World Wide Web have grown immensely in popularity in 
recent years. The internet is now probably the largest single information source in the 
world. Using internet web browsers (such as Microsoft Internet Explorer), users can 
access information or documents from internet web servers over the internet using the 
HyperText Transport Protocol ("HTTP"). Internet web browsers provide a convenient 
user interface allowing the users to receive and display information from internet web 
servers. Internet web servers are set up and maintained by individuals or companies 
wishing to publish content on the web. Each web page on the internet contains an unique 
Universal Resource Locator ("URL") address. An internet web browser retrieves and 
displays the document located at a specific URL address. An internet web browser 
displays only that information which is specified by instructions in the source document 
specified by the URL address. Often, the instructions in the source document give 
hypertext links to other documents. Hypertext links are simply instructions to the internet 
web browser to replace the currently displayed source document with a new document 
located at another URL address. When the user clicks on the hypertext link, the web 
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browser retrieves the new document from the URL address and displays it to the user. 
Hypertext links in a web page document are specified by the author of the web page 
document. If a user wishes to load another document for which there is no hypertext link 
on the currently displayed document, the user must enter a new URL address manually or 
by use of a list of saved URL addresses stored in the web browser and known as 
"bookmarks." 

Often, a person wishes to send an internet web document to another person. This 
is most often achieved by copying the URL address of the web document into an email, 
and emailing it to the recipient. When the recipient receives the email, they can then load 
that URL address into their internet web browser, which will then retrieve and display 
that web document. If a user wants to direct a user to more than one web document, the 
user can copy and paste multiple URL addresses into an email and send that on to the 
recipient or recipients. In this way, a user can share web pages of interest with others. 
Some browsers also have a built-in command such as "Send Page" which will 
automatically launch the user's email program with either the URL link or the complete 
page inserted into the email. 

If several users wish to communicate regarding aspects of certain web pages, they 
must do so in person, using voice communication via telephone, or using email. This 
becomes clumsy if more than a few users are involved. Furthermore, such methods of 
communication are difficult since the communication is lacking the web page itself and 
cannot be referred to easily. It is communication without context. 
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What is missing from the internet today is a method of packaging up several web 
pages, regardless of their host domain, into a navigable apparatus, and with contextual 
communication functionality built-in. The present invention described in this application 
presents just such a solution, using methods and an apparatus for which the inventor 
seeks patent claims. 

Another problem with the internet today is that it is desirable to self-publish 
content and and associate the content with digital media files. The present invention 
presents methods and an apparatus for which the inventor seeks patent claims. 

Another problem with the internet is that searching the internet for documents is 
an explicit act performed at a web site existing for that purpose. The present invention 
described in this application enables contextual web page information search to be 
automatically performed in a media player and results displayed therein, thus establishing 
a new search paradigm that negates the need to visit a web site dedicated to search and to 
increase accuracy of results by narrowing the search by the context of the digital media 
being played. 
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DETAILED DESCRIPTION OF THE INVENTION 



The following detailed description sets forth numerous specific details to provide 
a thorough understanding of the invention. However, those of ordinary skill in the art 
will appreciate that the invention may be practiced without these specific details. In other 
instances, well-known methods, procedures, protocols, components, algorithms and 
circuits have not been described in detail so as not to obscure the invention. 

In one embodiment, the present invention discloses a method and apparatus by 
which the user can gather the URLs for specific web pages from the World Wide Web, 
arrange them into a navigable webpipe, enable contextual communications therein and 
store the webpipe for access by others. Furthermore, the present invention enables notes 
and advertisements that are contextually relevant to specific web pages to be stored in a 
database and accessed by others. 

Figure 1 shows the button 105 to invoke an embodiment of the present invention. 

Figure 2 is an exemplary flow diagram illustrating one embodiment of the 
invention. In this embodiment, the user decides to create a webpipe. As the user 
navigates the World Wide Web with their web browser, they encounter web pages of 
interest that they wish to add to their webpipe, as shown in step 105. The user then 
launches the SidePipe client application as shown in step 110. If the user has not yet 
initialized the webpipe, they do so as such in step 115. They then add the web page URL 
to the webpipe as shown in step 120. In one embodiment, the user now gives a name to 
this page of their webpipe, and can add comments to the page if they wish, as shown in 
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step 125. This process continues until the user has finished adding web page URLs to the 
webpipe. At this point, the user can view the webpipe as shown in step 130. The user 
can also email the webpipe to a recipient as shown in step 135. When the recipient 
receives the email, they load the URL address given in the email into their web browser, 
either by clicking directly on the hypertext link or by copying/pasting the URL address 
directly into their web browser. This is step 140. The URL address for the webpipe 
accesses a central web server, as shown in step 145. This web server contains a database 
that contains the URL addresses, page titles and comments which the author of the 
webpipe created. The technology then assembles the webpipe by dynamically building a 
webpipe index page. This happens by a database query which retrieves from the database 
all of the pages of the specified webpipe. Each page in the webpipe consists of the URL 
address of the web page, the user title for that page in the webpipe and author comments 
for that page. Also contained in the database is the order in which the pages are to be 
presented. All of these data are then formatted to display as an index page. Furthermore, 
the database contains other data relevant to each page. An embodiment of this in the 
present invention is a message board with which readers of the webpipe may read 
messages from others and post their own messages. Many other mechanisms for 
communication which are relevant contextually to the specific web page in the webpipe 
are also envisioned, such as multiple-choice answer forms, polling mechanisms, etc. The 
common characteristic of these mechanisms is that they enable communication that is 
relevant to each individual web page in the webpipe. 

As mentioned, every web page in the internet has a unique URL address. The 
present invention has a method by which the URL of the web page that the user's web 
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browser is currently displaying can be determined, and communicated to a central server. 
One of the standard features of a web browser is the ability to "bookmark" a web page 
URL. A bookmark allows for easy navigation back to that web page, without the user 
having to remember and type the URL of the web page. One of the limitations of the 
bookmark mechanism in web browsers is concerned with web pages that are constructed 
with "frames." Frames are a structure built-in to the HTML page description language 
and supported by most internet browsers. Frames allow a web page to actually be 
comprised of several separate documents. Essentially, frames allow for a web page to be 
displayed with multiple "panes" with each pane containing a separate document, each 
document retrieved from an unique URL address. To the user, the web page displayed by 
the web browser appears as an integral unit. However, as noted, the displayed page is 
actually a composition of several documents. This is a popular technique used in the 
authoring of web pages. Often, it is used to simplify the design and user interface of the 
web site for the user. For a web site that has many web pages and which requires a 
mechanism for navigation to those pages, the navigation mechanism is often put into a 
separate pane that remains static and always available to the user. When the user clicks 
on a navigation link in that pane, the document corresponding to the URL specified by 
that navigation link is loaded into a separate, neighboring pane. In this way, the 
navigation panel is a separate unit from the pane displaying the requested document. To 
the user, the navigation pane remains static and always available, allowing them to select 
the documents displayed in the other panes. 

In HTML (hypertext markup language), the most common language for authoring 
web pages, frames are specified by a "parent" document which per se specifies the 
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arrangement of panes. The arrangement of the panes is generally called the "frameset" of 
the web site. When a user loads a web site into their browser, the URL actually specifies 
the URL of the document that defines the frameset. The URL of this document 
containing the frameset description is the address of the web site as shown in the URL 
address display area of the user's web browser. In fact, all of the URLs for the documents 
that are loaded into the individual panes described by the frameset are obscured to the 
user. No matter how the user navigates through the web site, the URL displayed in the 
browser address area to the user remains the same — that of the document describing the 
frameset. Discerning the URL addresses of the individual documents in the panes is 
possible, but beyond the abilities of the non-technical user. The problem presented by 
frames is that when the user bookmarks the page, despite how they have navigated 
through the web site, it is the URL of the document describing the frameset which is 
saved. When the user then uses the bookmark which they have stored in their browser to 
navigate back to that web page, it is the frameset document that is loaded. Since the 
frameset document specifies only the initial documents to be loaded into its child panes, 
the bookmarked frameset will always load the top-level starting point of the web site, 
commonly called the "home page," regardless of the actual documents loaded into the 
frameset's panes at the time that the user creates the bookmark. This presents the user 
with the experience of having navigated to a specific page within a web site which is 
defined with frames, and bookmarking that page. Upon loading the page, the web 
browser loads the frameset document, which in turn loads into each pane of the frameset 
the documents specified in the frameset. This always loads the "home page" of the web 
site, with all of the initially defined pane documents, instead of the documents that were 
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loaded into the panes at the time that the user created the bookmark. This is an excellent 
example of the current state of the technology for discerning URL addresses. The current 
web browsers from vendors such as Microsoft and Netscape all work this way. They 
discern the governing parent document that gives the frameset, not the individual pages 
loaded at any one time in the panes. 

Web browsers do have knowledge of all of the URL addresses of documents 
loaded into the individual panes of a web site that uses frames. However, the current 
state of the art does not enable the identification of the key content document currently 
displayed. For example, consider a web site using frames which has a frameset which 
specifies two panes: a small pane on the left giving navigation links and a larger pane on 
the right which displays the "content document" specified by the links in the left pane. 
The current state of the art does not allow for identification of the pane that contains the 
content document. To the web browser, there are simply two panes, each displaying a 
document identified by a URL address. The present invention furthers the art by giving a 
method by which the content page is discerned. This method is now described. 

The method works off of the observation that the pane that displays the content 
document is almost always the largest pane in the frameset. It is a phenomenon that the 
designers of web sites that use frames design the frameset which describes the geometry 
and relationship of the panes within it to give maximum area to the content document. 
Thus, the URL of the key content document is that which is currently displayed in the 
largest pane of the frameset. The present invention determines which of the panes in the 
frameset has the largest area, and then retrieves the URL for the document. The present 
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invention then communicates that URL address to a central server. Since the URL 
address of a publicly available web document is by definition unique, that URL can serve 
as a key in a relational database. The database can then relate other data to that key. The 
present invention uses database keys derived from the unique URL addresses to associate 
relevant data, such as a message board, to web pages. 

An embodiment of the present invention is a button that is added to the web 
browser. This is shown in Figure 2. This button, when clicked, is an event that invokes 
the method that determines the URL of the content page. Those with ordinary skill in the 
art will recognize that other embodiments could have different event triggers other than 
the button described herein, and which is the preferred embodiment. For example, the 
method could also be invoked by the action of pressing a certain keyboard key 
combination or a uttering a specific voice command. Regardless of how the method is 
invoked, the resulting URL of the content page as determined by the method is then 
transmitted to the central server. In an embodiment, the method invoked by the button 
also launches a small client window on top of the current browser window. This is called 
the 'SidePipe Client." The SidePipe Client is the apparatus by which the user determines 
what other methods of the invention should be invoked. An embodiment of the present 
invention allows for three general functions: Add the URL to a webpipe, access or create 
notes that are associated to that URL, or access other data that are contextually relevant to 
that URL (such as advertisements from third parties). Each of these functions will now 
be described in turn. 
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As described earlier, the user first navigates to a web page to which they wish to 
apply the present invention. Once the web page is loaded and displayed in the user's web 
browser, the user invokes the SidePipe Client. An embodiment of the present invention 
has said invocation achieved by the clicking of a button installed on the web browser. 
When clicked, the button does two things: 1) It invokes the process described above 
wherein the content page URL is discerned by calculating the area of each pane. The 
largest pane is considered to hold the URL of the Content Document; 2) It opens a new 
browser client window, called the SidePipe Client, on top of the current browser window, 
with data and documents retrieved from a central web server to which the URL of the 
Content Document has been transmitted. The client window that opens stores the value 
of said Content Document URL as a variable that is accessible to the SidePipe Client. 
The SidePipe Client can then retrieve this URL value as needed to transmit to the Central 
Server as part of client/server function calls. 

When the SidePipe Client is launched, then, it has knowledge of the Content 
Document URL that was in the web browser when the user first invoked the SidePipe 
Client. At this point, the user has discretion as to which of the SidePipe Client functions 
the user wishes. In an embodiment of the present invention, the user has three choices, 
which are covered by three general function types: webpipes, WebNotes, and Associated 
Services. Each of these general functions is now described in detail. 

In one embodiment of the present invention, the "webpipe" is The webpipe is 
composed of four key components: 

1. Index page giving the contents of the webpipe. 
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2. The URLs of the pages in the webpipe 

3. The author-generated content for each page in the webpipe 

4. Communication data for each page in the webpipe 

The webpipe author creates the webpipe within their browser experience. As the 
author views web pages with their browser, they may find pages that they wish to include 
in a webpipe. The first step for the author is to navigate to the web page that they wish to 
add to a webpipe. With the desired web page loaded and displayed by the author's web 
browser, the author then invokes the program code for the present invention. As noted 
above, an embodiment of this is by the method of clicking a button that has been 
downloaded and installed on the user's web browser. Upon clicking this button, the 
program code of part of the present invention is invoked. As described above, the code 
discerns the Content URL of the presently loaded web page (via the process described 
above). In an embodiment of the present invention, a client browser window is then 
loaded on top of the current browser window, with content supplied by the central 
SidePipe server, to which the URL discerned by the code invoked by clicking the 
SidePipe button has been supplied. Thus, the SidePipe client window that launches on 
top of the current browser window contains the Content URL as a value assigned to a 
variable within the SidePipe client browser window. That URL can then be accessed by 
the SidePipe client browser to be passed back to the Central Server as needed. 

In the creation of the webpipe, the user first creates a named webpipe. When the 
author first creates a webpipe, and assigns a name to it, that name is transmitted to the 
Central Server and the appropriate entries are made in the SidePipe databases. In the 
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present embodiment of the invention, there is the concept of the "current active webpipe." 
This is a user interface technique used to make additions to the webpipe quicker. The 
author in general will tend to focus on completing one webpipe at a time, and the "current 
active webpipe" approach enables the author to quickly add web pages to a webpipe 
without having to always specify the webpipe to which each page is to be added. 

In an embodiment of the invention, the user, by clicking the "add page to pipe" 
command in the SidePipe client window, adds the URL of the Content Page as discerned 
by the Launch Code, to the Current Active webpipe. The user is then presented with the 
opportunity to add a descriptive title to that page in the webpipe, and to add any 
descriptive notes to that page. The "Page Title" and "Page Note" will be part of the 
webpipe, able to be read by the recipient of the webpipe. After entering the Page Title 
and the Page Description, the author clicks the "submit" button. The SidePipe Client then 
transmits the URL, Page Title, Page Description, Page Number, User handle, and User 
Password to the Central Server. Using standard relational database methods, the Central 
Server code first verifies the User Password matches the User. If yes, then the code adds 
the URL, along with the Page Title and Page Description, to the database. Furthermore, 
the order of the page within the webpipe, which is specified by the Page Number, is also 
set in the database. At this point, the author is finished with adding this page to the 
webpipe. They can now close the SidePipe Client and return to surfing the web, and to 
add another page to a webpipe using the method described above. 

The present embodiment of the invention allows for other commands relevant to 
the creation of webpipes. These other commands are: 
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View Pipe. Launches the webpipe in a separate, full-size browser window so 
that the author can play the Current Active webpipe, and thus experience the 
webpipe as a recipient would. 

• Email Pipe. This command, through standard techniques familiar to those 
with ordinary skill in the art, launches the author's email system, with an email 
message with the link to the webpipe pre-written and ready to be sent to the 
recipient. 

• Delete Pipe. This command sends a message to the Central Server to delete 
from the database the user's current active webpipe. 

In addition, the individual pages in a webpipe may be edited. The author can 
delete any page completely from the current Active webpipe. They may also edit the 
Page Title and Page Description that they entered for a specific page in the webpipe. The 
author can also re-arrange the order of the pages in the webpipe. 

An important feature of the webpipe playback apparatus is that it is entirely 
HTML-based, and requires no supplemental software be installed on the user's computer 
to view the webpipe. The webpipe Viewer is constructed dynamically by the SidePipe 
Server and is accessed through a URL input into the browser, either manually typed or 
through clicking a hyperlink. The webpipe Viewer thus behaves like any other dynamic 
web document. The URL for the webpipe contains name/value pairs that are passed to 
the SidePipe Server. In the present embodiment of the invention, these name/value pairs 
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are: The ID number of the webpipe which the SidePipe Server uses to get the proper data 
from the SidePipe Server Database relevant to the specific webpipe; a key value which in 
combination with the ID number are unique and used for validation; and a "Skin ID" 
which is used by the SidePipe Server program to set the branding and look and feel of the 
webpipe Viewer. 

When the user loads a webpipe for viewing, the SidePipe Server uses the 
name/value pairs provided in the URL to perform queries on the SidePipe database, and 
to retrieve the data specific to that webpipe. In the present embodiment of the invention, 
that information includes the URLs of the web pages that were added to the webpipe by 
the webpipe Author, and the title and that the webpipe Author added during the webpipe 
creation process. These data are then assembled into an index and listed in tabular 
format. In the present embodiment of the invention, the webpipe Viewer consists of three 
distinct parts: A "Navigation Pane" which enables the user to navigate through the 
webpipe; a "Content Pane" which displays the web pages that the webpipe Author put 
into that specific webpipe; and a "Contextual Data Pane" where data such as message 
boards are displayed. These three distinct parts are shown in Figure 3. 

When the webpipe is loaded into a user's browser, the initial appearance has the 
index page that has been constructed by the SidePipe Server displayed in the Content 
Pane. This enables the user to view the title and description of the webpipe as created by 
the webpipe Author. In addition, the title and description of each page in the webpipe, as 
created by the webpipe Author, is listed. These page listings are constructed as 
hyperlinks that allow the user to jump to any page in the webpipe. Figure 3 also shows 
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the Navigation Pane that gives controls for moving serially forward or backward through 
the webpipe. The "Index" button returns the user to the start of the webpipe with the 
index page loaded in the Content Pane. These controls thus give the user navigational 
power to move forward or backward through the webpipe, or to jump to any specific 
page. 

After the initial index page, the user then navigates through the webpipe. When 
the user navigates to a new page in the webpipe using the methods described above, a 
command in the form of name/value pairs and transmitted via standard HTTP methods is 
sent to the SidePipe Server. The SidePipe server then queries the SidePipe Database and 
retrieves the data associated with that page in the webpipe. In the present embodiment of 
the invention, the SidePipe Server then provides updated data to two of the panes in the 
webpipe Viewer: The Content Pane is directed to load the web page located at the URL 
that webpipe Author added during the authoring process. That web page is then loaded 
directly from whatever web server responds to that URL address. Since the web page 
shown in the Content Pane is served directly from the source web server, the content of 
that web page is not guaranteed to be the same as it was when the webpipe Author added 
that web page to their webpipe in the authoring process. This is beneficial in that time- 
sensitive web pages, such as those providing news articles and other timely matter, will 
be up-to-date whenever the webpipe is viewed. For example, the webpipe Author could 
create a webpipe consisting of news sources, and even if the webpipe is viewed far into 
the future from the date of creation, the content will be up-to-date. The other pane that 
gets updated by the SidePipe Server is the Context Pane. The SidePipe Server Database, 
using standard relational database techniques, associates specific data that resides on the 
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SidePipe server with the URL of the web page displayed in the Content Pane. In this 
way, data objects such as message boards can be displayed in the Context Pane that are 
specifically relevant to the URL of the web page shown in the Content Pane. During the 
webpipe authoring process, the webpipe Author associates a title and description with 
each web page that they add to a webpipe. That data is stored in the SidePipe Database 
on the SidePipe Server, and using standard relational database techniques, those data are 
associated with the web page. Upon playback of the webpipe, the SidePipe Server is thus 
able to populate the Context Page with data relevant to the web page displayed in the 
Content Pane. In the embodiment of the present invention, a message board is one of the 
data types that the webpipe Author can optionally specify appear in the Context Pane of 
every page in the webpipe. As a recipient of a webpipe progresses through the webpipe, 
a separate and distinct message board appears in the Context Pane. Every recipient of the 
WebPage sees the same message board, thus allowing collaboration between different 
persons viewing the same webpipe. Furthermore, each page in the webpipe has a 
separate and distinct message board. Thus, a webpipe that consists of three pages has 
three separate and distinct message boards, one for each page of the webpipe. Since the 
message board in the Context Pane is shown while the web page is shown in the Content 
Pane, all recipients of the webpipe see both the message board in the Context Pane and 
the web page in the Content Pane simultaneously. Other data types besides message 
boards can be placed in the Content Pane, and like the message board, any other data is 
also likewise stored on the Central Server. 

Figure 5 is an exemplary flow diagram illustrating one embodiment of the 
invention. This embodiment is an enhancement to a software program known as a "media 
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player" which purpose it is to play audio files or show video clips on the user's computer. 
Most media players for computers are designed to accommodate enhancements through a 
"plug-in architecture" which allows third parties to enhance and extend the functionality 
of the media player. The present embodiment of the invention is an enhancement to the 
media player and inserts a web browser control into the media player. The web browser 
control provides a region in which HTML documents can be displayed. The present 
embodiment of the invention displays a web page assembled by the SidePipe Central 
Server. When the user plays an audio file or video clip in the media player software, the 
present embodiment determines, through the API (Application Program Interface) 
provided by the media player software, specific information about the media currently 
playing. Such information is referred to as the metadata of the media file. The metadata 
includes the artist or author of the content, the name of the content, and other data 
appropriate to type of media file. For example, an MP3 audio file usually contains 
metadata for the artist, song title, album, year, and genre. The invention obtains this 
information from the media player software through its API , and this data is then 
transmitted to the SidePipe Central Server. 

The present embodiment of the invention uses the metadata information in its 
method of associating external content with the media file. An embodiment of the 
invention has a relational database program running on the central server. This database 
essentially preserves associations between media files and independent content. We will 
now describe the organization of the database tables that accomplish that. Those with 
ordinary skill in the art of database design will recognize that there are designs of the 
database that could yield similar results, and the design herein described is not intended 
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to limit the scope of the invention. The present embodiment creates relational database 
tables to associate content with the media file. The media file thus becomes a nexus 
through which other media can be associated and accessed, uses the author and tide of 
the media to form the key, but other metadata could also be used. For example, many 
audio files contain a metadata field with a unique identification number. Since it is 
unique, this number could also be used as the key. However, the use of such 
identification numbers at present is not universal. Thus, the present embodiment uses a 
key constructed from the author and title. Consider the song "Hey Jude" by "The 
Beatles." This artist and song title, considered together, form an identification that gives 
a very high degree of uniqueness. This pair allows the present embodiment to form 
query parameters to extract data from a relational database. The present embodiment 
contains a relational database table that has fields that correspond to the standard 
metadata tags present in the media files. For audio files, those metadata tags are artist, 
title, album, genre and year. Within that table there is a field that contains a list of the 
identification numbers of webpipes that are associated with that particular media file. For 
example, let's say that the webpipes with ID numbers of 345 and 676 have been 
associated with the song "Hey Jude" by "The Beatles". If we perform a query on the 
database, we can ask the database to return the list of webpipes where artist=The Beatles' 
AND title='Hey Jude'. The database will return the list [345, 676]. Further refinement 
is also possible on the query, since songs are often part of albums. For example, the song 
"Hey Jude" by "The Beatles" was issued as a single, but it is also found on the albums 
"Hey Jude", "The Beatles 1967-70" and "The Beatles Past Masters Volume 2." Thus, 
"album" can be an additional field in the database that we can use to further refine the 
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search. We could, for example, query the database and ask for the list of webpipes for 
which artist = The Beatles' AND title=Hey Jude' AND album=The Beatles 1967-70'. 
The resulting list would not necessarily be the same as the list provided by a query using 
just artist='The Beatles' and title='Hey Jude'. This method of associating a list of 
webpipes with songs in this way enables differentiation between versions of songs, 
particularly with live albums that have the same song titles as studio releases, but are 
actually different performances. 

In one embodiment, the invention provides for several types of data to be 
associated with a media file. These are webpipes, messages boards, blogs and 
promotional pieces. These are each described in turn. 

webpipes have been fully described above. In this embodiment, the operator is 
shown a list of webpipes that others have associated with the media that they are 
currently playing in their media player software. The operator is also given the 
opportunity to associate any webpipes that they have created with that media file. Thus, a 
list of the webpipes that they have authored is displayed. A checkbox is located next to 
each webpipe listing, the purpose of which is for the operator to indicate which webpipes 
they want associated with the media. 

Message boards are a common mechanism on web sites. The software 
architecture of message boards traditionally is that the topic of a message board thread is 
usually the key to finding the messages that belong to the thread. The present invention 
instead uses the metadata tags as fields to pre-filter the message topics. When an 
operator is playing media in their software media player, the metadata of the currently 
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playing media is transmitted to the Central Server, along with the mode of the invention. 
If the mode is "message board" then a database query is performed, requesting all 
message board topics where the artist and title match. The resulting topics are then 
assembled in order of most recent and transformed into table format and sent to the client 
for display to the operator. In this way, only topics that were posted by the operator or 
others during the playing of that media are displayed. When the operator clicks on a 
topic, all of the messages posted to that topic are then displayed. The topic id code is 
transmitted to the Central Server, which then performs a database query to assemble all 
messages, in order of most recent, of messages posted to that topic. Every message 
occupies a row in the messages table. One of the fields of that table is the topic id. If the 
operator creates a new topic, the name of the topic, along with the metadata of the current 
playing media, is transmitted to the Central Server. In the 'Message Board Topics' table, 
an entry is made. The fields of this table consist of the metadata tags from the media, 
plus a unique integer id field created by the database. When a message is posted under a 
topic, the message, author and topic id are transmitted to the Central Server. An entry is 
then made into the 'messages 1 table, with the topic id enabling the message to be extracted 
as part of the results of a database query where the topic id is the parameter of the query. 

All data types follow this method. The key point is that a table exists where there 
is a field for each of the metadata tags in a media file type. Those metadata tags, all or in 
part, are used as parameters to extract a list of content units that are associated with that 
media. In the present invention, the extracted list is a list of keys into other database 
tables that contain the actual data. Those skilled in the art will recognize that there are 
other ways to arrange the database tables to achieve the same end, but that using the 
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metadata tags as fields in the database table to organize the data and perform queries will 
be the same. 

Digital media files such as audio files and video files are played on a computer 
using a media player. Media players generally provide the ability to enhance their 
capability by installing a plug-in. A plug-in can be developed either by the vendor who 
makes the media player, or by third parties if the vendor provides a development kit for 
their media player. The development kit usually documents the Application Program 
Interface (API) which describes the services that the main program provides to a plug-in, 
and how a plug-in should interact with the host program. An embodiment of the present 
invention is a plug-in for media players which enables a central server to provide the 
plug-in with additional content resources appropriate to the currently playing media item. 
The present invention listens for events such as a new media item beginning to play. The 
present invention then acquires, through API calls, the metadata from the currently 
playing media item. This metadata is then transmitted to the central server. The central 
server performs a database lookup to see if any content resources have been associated 
with the currently playing media item. The associations are stored in a relational 
database. The metadata consists of several fields of data. For example, audio files 
usually contain fields for artist, title, album, genre and year. The present invention 
duplicates the same fields in its relational database tables. When an association is made, 
those fields in the relational database are populated with the metadata field values. This 
enables a database retrieval of data associated with a particular media file. 
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Search engines are an essential part of the internet browsing experience. Search 
engines catalog all of the web pages on the internet, and associate them with keywords. A 
typical search engine sessions goes as follows: A search engine user goes to the search 
engine web site, types in their key word(s) and the search engine then returns a list of web 
pages in which the keywords appear. Through the use of boolean operators, searches can 
be narrowed. The problem is that searches are performed without any context, and 
results are not as accurate as they could be. An embodiment of the present invention 
provides for an improved search paradigm. The present invention takes advantage of. the 
fact that knowing the context of a search can greatly improve the results. As mentioned, 
an embodiment of the present invention is a plug-in for media players. When a media 
asset is played, such as an audio file, the present invention obtains the metadata for the 
media asset. In the case of an audio file, the present invention obtains the artist, title, 
album, genre and year. Often, not all of those fields contain data. However, they almost 
invariably contain the artist and title data at a minimum. Since we know the context (the 
artist and the title of the song), we now have context to perform highly accurate searches. 
Furthermore, since we have context, we can anticipate the types of searches most users 
will do. With regard to music, most listeners will perform searches to find web pages 
that give them information about the artist and the song. That is, information about the 
artist such as how many other songs they have made. Much of the best information 
comes from a relatively small number of web sites. These web sites are mostly online 
versions of print publications, such as rollingstone.com and vibe.com. The present 
invention takes advantage of the fact that to navigate to a page about a specific artist, one 
must at one point click on a hyperlink that gives the artist's name. All search engines use 
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what is known as a "spider" to find out information on web sites. A spider is software 
that is programmed to automatically visit a plurality of web sites and to retrieve a 
plurality of web pages from those web sites. The spider software functions in an 
automated manner by retrieving the top-level page of a web site, known as the home 
page, building a list of all hyperlinks on the page, then retrieving each web page referred 
by the links and repeating the process. In this way, the spider descends through the 
hierarchy of all pages in the web site and retrieves all pages in the web site. Those 
retrieved web pages are then converted into structured data that is entered into a database 
on a central server, the database being searchable for keywords that appear in the web 
pages. The database is organized such that the URL of the document that contains the 
keywords input as search parameters can be determined. Search engines thus retrieve 
from the database all of the URLs of documents that contain the keywords input by the 
operator. A search engine will then arrange the list of URLs and format them so as to be 
displayable in a web browser. An important point to consider about the usage paradigm 
by an operator using the search engine software is that the input of keywords is a manual 
operation, and that going to a search engine web site is a conscious action of the operator. 

Figure XX is an exemplary flow diagram illustrating one embodiment of the 
present invention. The present invention alters the traditional search paradigm by 
spidering only those web sites known to have particular relevance to the media files. 
Again, taking our music file example, the present invention spiders such music sites as 
rollingstone.com, vibe.com, mtv.com, allmusic.com and others. The index pageThe 
spider then, as other spiders do, obtains a list of the hyperlinks on each page and retrieves 
other pages in the web site. As mentioned, the hyperlink to a specific artist page is 
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usually labeled with the artist's name. Furthermore, navigation hyperlinks to those web 
pages concerning a specific artist are usually listed on a single index page, or a series of 
index pages. The present invention takes advantage of that by first retrieving the index 
page, or the starting index page if there are a series of them. The present invention then 
retrieves all hyperlinks on the index page, and inputs 

In this embodiment, a list of target web sites is created as shown in step 105. The 
spider visits each web site one at a time as shown in step 1 10. If the web site has not been 
visited before or is a new web site, a site map is created for web site in step 115. The site 
map contains some basic information about the web site including how the web site 
groups its pages and how it encodes its hyperlinks to pages containing information for a 
specific artist, song, album, or genre. The site map remains the same as long as 
organization of the web site remains unchanged. In one embodiment, the URLs of web 
pages that contain information specific to an artist, song, album or genre of music are 
stored in a database, along with the name of the artist, the name of the song, the name of 
the album, the type of genre, in whatever combination is appropriate for the hyperlink. 
This is shown in step 120. In order to ensure that the hyperlinks are up to date, a web site 
may be visited periodically. 

Figure XX is an exemplary flow diagram illustrating a method for searching a 
database structured and populated with data as described above. In step 110, the search 
parameters are input. The search parameters are limited to any combination of the 
database metadata fields described above. In step 1 15, a database query is constructed 
using the parameters provided. In step 120, the database query returns a list of database 
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entries for which the parameters given as input are satisfied. In step 120, the results are 
formatted such that they can be displayed in a client computer. 

An embodiment of the present invention is concerned with the organization and 
presentation of content resources relevant to specific digital media. Every digital media 
type has certain specific metadata fields that have special meaning. For example, the 
primary metadata fields pertaining to digital audio media may be comprised of the artist, 
song title, album title, genre, and year fields. The primary metadata fields for video files 
may be comprised of title, leading cast, secondary cast, producer, director, genre, rating, 
and year. Since different media file types have different metadata fields, this presents a 
problem with the organization of a database that can store and retrieve metadata fields in 
a generic sense and be applicable to different media types. The present invention 
resolves this by creating a media type map, which maps the specific metadata fields 
appropriate for a specific media type to generic metadata fields in a database. The 
database has n number of generic metadata fields, which may be labeled metadata_l 
through metadata_n, n not being limited in theory but in practice being between 5 and 10. 
Taking as an example the audio media type, the media type map for audio type media 
would map the field of artist to the metadata_l field in the database, the field of song title 
to metadata_2 field, the field of album to metadata_3, the field of genre to metadata_4, 
and the field of year to metadata_5. All other fields in the database beyond those mapped 
by the media type map would contain empty values. Thus, if the database has 10 
metadata fields, in the example of the audio media type, the database fields metadata_6 
through metadata_10 would have empty values. If we apply this to the video media type, 
the video media type map would map the metadata fields for the video type media of 
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title, leading cast, secondary cast, producer, director, genre, rating, and year to database 
metadata fields metadata_l through metadata_8, respectively. All other database 
metadata fields beyond metadata_8 would contain empty values. In this way, the present 
invention is able to apply methods to store, retrieve and process database entries that are 
agnostic with regard to the media file type. 

The following is an example of the media type map code to describe the mapping 
of audio file types to the database: 

audio_file_map = { 

"database field mapping" : { 

"metadata_l" : "artist", 

"metadata_2" : "song title", 

"metadata_3" : "album title", 

"metadata_4" : "genre", 

"metadata_5" : "year", 

h 

"field grouping" : [("artist",), ("artist", "song title"), ("artist", "album"), 
("artist", "song title", "album"), ("genre",), ("year",), 
("genre", "year")], 

} 
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The media type mapping is here constructed as an associative array, a data 
structure known to those with ordinary skill in the art. However, those with ordinary skill 
in the art will recognize that there are other common data structures that could represent 
the media type mapping. The associative array structure given here is not meant to limit 
the scope of the present invention, but to give a common structure know to those with 
ordinary skill in the art to the media type map for the purpose of describing the media 
type map. There are two aspects to the media type mapping language, the database field 
mapping and the field grouping. In the example above, the entry "database field 
mapping" specifies the mapping of metadata fields specific to the audio media type to the 
generic database metadata fields. The entry "field grouping" specifies which fields either 
alone or in combination have relevance to the media type. In the example above, the 
groups given are the following list: [("artist",), ("artist", "song title"), ("artist", "album"), 
("artist", "song title", "album"), ("genre",), ("year",), ("genre", "year")]. Those with 
ordinary skill in the art of programming will recognize that this is a list of tuples. A tuple 
is a common data structure that is immutable and thus can be hashed and used as a key in 
a hash table. This creates a type of database wherein data is stored and retrieved by 
means of the unique, hashable tuples given above. For example, consider an the song 
"Hey Jude" by the artist 'The Beatles". This song is from 1969, is a rock song, and was 
available as a single and on the albums "Hey Jude", "The Beatles 1967-70" and "The 
Beatles Past Masters Volume 2." the resulting data structure would look like this: 

("The Beatles",) : [list of database Ids with matching metadata fields...], 



Inventor: Christopher Bohn tel. 415/388-4102 



Page 32 



("The Beatles", "Hey Jude") : [list of database Ids with matching metadata 
fields...], 

("The Beatles", "Hey Jude", "Hey Jude") : [list of database Ids with matching 
metadata fields...], 

("The Beatfes", "Hey Jude", "Past Masters Volume II") : [list of database Ids with 
matching metadata fields...], 

("The Beatles", "Hey Jude", 'The Beatles 1967-1970") : [list of database Ids with 
matching metadata fields. . .], 

("The Beatles", "", "", "", "1968") : [list of database Ids with matching metadata 
fields...], 

Thus, if we wanted a list of all URLs for web pages from select web sites that 
have information relevant to the song "Hey Jude" by "The Beatles", we could simply 
retrieve the list from this data structure that is associated with the tuple ("The Beatles", 
"Hey Jude"). If we wanted a list of the URLs for web pages from select web sites that 
have information relevant to the "The Beatles" in the year "1968", we would retrieve the 
list associated with the tuple ("The Beatles", "", "", "", "1968"). With this method, we 
can retrieve lists for many combinations of parameters. This also makes it possible for 
the present invention to automatically create and populate web pipes with URLs to web 
pages specific to a set of parameters appropriate to the media type. This data structure is 
hereafter referred to as the "parameterized data". 
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Figure XX is an exemplary flow diagram illustrating how web pipes can be 
automatically created and populated with URLs from the parameterized data described 
above. In step 205, all of the keys to the parameterized data are retrieved. In step 210, the 
list associated with each key in the parameterized data is then retrieved, with the list 
consisting of the IDs of entries in the database tables. In step 215, a webpipe is created. 
In step 220, the URL for each entry in the database table with the ID present in the list of 
IDs retrieved from the parameterized data are added to the webpipe. 
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